home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7682 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 KB
  1. Path: goanna.cs.rmit.EDU.AU!not-for-mail
  2. From: rav@goanna.cs.rmit.EDU.AU (++           robin)
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: 28 Feb 1996 18:58:03 +1100
  6. Organization: Comp Sci, RMIT, Melbourne, Australia
  7. Message-ID: <4h11ub$njp@goanna.cs.rmit.EDU.AU>
  8. References: <4gh5ru$eng@goanna.cs.rmit.EDU.AU> <312CCEB2.4AB7@corp.dialog.com> <4grhtv$s31@goanna.cs.rmit.EDU.AU> <4gt0tv$826@solutions.solon.com>
  9. NNTP-Posting-Host: goanna.cs.rmit.edu.au
  10. X-Newsreader: NN version 6.5.0 #0 (NOV)
  11.  
  12.     seebs@solutions.solon.com (Peter Seebach) writes:
  13.  
  14.     >In article <4grhtv$s31@goanna.cs.rmit.EDU.AU>,
  15.     >++           robin <rav@goanna.cs.rmit.EDU.AU> wrote:
  16.     >>---The basic operations of string-handling are done somewhat
  17.     >>clumsily in C -- catenation is a simple infix operation
  18.     >>in PL/I, but you must use a function in C, and then it
  19.     >>catentates the second operand to the first.  Nothing like
  20.     >>c = d || e;
  21.     >>(And what happens when, in strcat(s1, s2), the sum of the lengths
  22.     >>of s1 and s2 exceeds the declaration for s1?!?!?
  23.  
  24.     >Then you invoke undefined behavior, and your code was illegal.  :)
  25.  
  26.     >Yes, C's string handling is primitive.  It also has no hidden overhead.
  27.  
  28. ---Well, it DOES have overhead.  First there's a procedure call
  29. and return.  That's overhead.  Second, to do a catenation,
  30. C has to search the first string s1, in order to find
  31. the null terminator, then append the second string s2.
  32. The search is overhead.  The overhead can be high for a
  33. long string (specially if just one character is appended).
  34.  
  35.     >>---again, for comparison, IF s1 > s2 THEN . . .  becomes
  36.     >>strcmp(s1, s2) . . . which yields neg, 0, or pos . . .
  37.     >>which leads to IF strcmp(s1, s2) > 0 . . .
  38.     >>which is scarcely intuitive [shades of the arcane FORTRAN
  39.     >>arithmetic IF].
  40.  
  41.     >I would kill for arithmetic if, simply because I frequently want to do
  42.     >one of three things bsed on the sign of an expression.
  43.  
  44. ---No need.  There's IF and SELECT, which will do the job
  45. in a much clearer fashion.
  46.  
  47.     >Once again, C has no hidden overhead, but has primitive functions. And?
  48.  
  49. ---Too right.  That's the crux.  They are crude, and don't include
  50. basic checks to see whether the pint pot is full (for example).
  51.  
  52.     >>   I'd agree with the statement about built-in functions.
  53.     >>PL/I for AIX and OS/2 now have BIFs for searching for specific
  54.     >>characters (SEARCH) either from the right or from the left,
  55.     >>searching for the absence of specififc characters (VERIFY)
  56.     >>from the right or left.
  57.  
  58.     >strchr, strrchr, strspn, strcspn, strpbrk.
  59.  
  60. ---strchr searches for just one character.  VERIFY searches for
  61. up to 255 characters.  SEARCH searches for up to 255 charcters.
  62. As for the others (strrchr etc), they are not in all systems.
  63. In other words, strchr is a trivial function that can be written
  64. as a compact search in PL/I even without using a function.
  65.  
  66.     >>   Furthermore INDEX, SEARCH, SEARCHR, VERIFY and VERIFYR
  67.     >>can start the search at any specified position (the three-
  68.     >>argument versions).
  69.  
  70.     >Same functions in C, you just use (s + 2) to start 2 positions in.  :)
  71.  
  72. ---They're not.  See above.
  73.  
  74.     >>   There are several functions for centering text, & trimming
  75.     >>given characters from either or both ends of a string.
  76.  
  77.     >sprintf.
  78.  
  79. ---Not quite.  The above are non-I/O functions.
  80.  
  81.     >>   And what happens when you actually w*a*n*t a zero byte in your
  82.     >>C character string?
  83.  
  84.     >All C character strings have a zero byte in them.  It's at the end.
  85.     >(But it *is* a part of the string, so far as I can tell.)
  86.  
  87.     >If you want an object which has characters possibly including NUL bytes,
  88.     >but is otherwise like a string, feel free to make one; it's trivial.
  89.     >It's just more expensive to run.
  90.  
  91. ---How is it trivial?
  92.  
  93.     >This is silly, though.  C is a low-level language by modern standards.
  94.     >So?  It's a design call.  You choose a language that meets your needs.  C
  95.     >meets my needs because it's available for the machines I want to use.
  96.  
  97.     >Let's try to keep the inter-language flame wars at a minimum, and if nothing
  98.     >else, let's try to keep it so that only people who know C very well and are
  99.     >comfortable with the whole library are discussing C's merits, and ditto
  100.     >for PL/I.  I certainly don't have the qualifications to bash PL/I, and I doubt
  101.     >you have the qualifications to bash C.  :)
  102.  
  103.     >(I can bash C, I just don't really want to.)
  104.  
  105.     >Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  106.     >C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  107.